[レポート] ビジネスの意思決定を加速する BI on Snowflake 設計の勘所 #SnowflakeDB #SnowdayJapan

[レポート] ビジネスの意思決定を加速する BI on Snowflake 設計の勘所 #SnowflakeDB #SnowdayJapan

Clock Icon2023.03.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2023年02月14日(火)、ANAインターコンチネンタルホテル東京、ならびにオンライン配信のハイブリッド形式でSnowflakeのイベント「SNOWDAY JAPAN」が開催されました。

当エントリではその中で、ブレークアウトセッションとして開催された「ビジネスの意思決定を加速する BI on Snowflake 設計の勘所」のレポートをお届けします。

セッション概要

当エントリで扱うレポートのセッション概要は以下の通りです。

[セッションタイトル]
ビジネスの意思決定を加速する BI on Snowflake 設計の勘所

[登壇者]
・三田 泰正氏(Snowflake株式会社 セールスエンジニアリング本部 シニアセールスエンジニア)

[セッション概要]
BI ソリューションは Snowflake に接続するデータアプリケーションの 1 つであり、大規模なデータから意思決定に役立つさまざまなインサイトを得る目的で、数多くのお客様に活用されています。しかしながら、その価値を最大化するためには、高いパフォーマンスで大規模データを可視化することが不可欠です。本セッションでは、BI ソリューションの具体例として Tableau を取り上げ、Snowflake の接続方式やキャパシティプランニングといったパフォーマンスに影響を及ぼす設計の勘所について説明します。

セッションレポート

はじめに

  • 本日のテーマは「SnowflakeとBI製品の連携、組み合わせ」。
  • メジャーな組み合わせではあるが、コストパフォーマンスを出そうとすると幾つか課題が出てくる。

Snowflake + BI製品のよくある課題

  • Snowflakeは数多くのBI製品と接続可能。接続自体はODBC/JDBC、またサードパーティコネクタ経由等で行う事が出来る。
  • ただ接続するのは簡単だがうまく使っていこうとするとSnowflake側に色々課題が出てくる。
    • (1).コスト:BIからのクエリをSnowflake側で処理=クエリの処理でウェアハウスを使用するため、想定以上にウェアハウスのコストが掛かる
    • (2).ダッシュボードのパフォーマンスが出ない:ダッシュボードが開かない、フィルタ切り替えによる再描画に時間が掛かるなど。またピークタイムにアクセスが集中することでパフォーマンスが落ちる
  • Snowflake+BIの組み合わせで高いコストパフォーマンスを実現するにはどうすれば良いか?
    • コストは出来るだけ下げたい
    • その上でパフォーマンスを向上させたい

コストパフォーマンスに効く設計ポイント

ライブと抽出

  • TableauからSnowflakeに接続する例 - 「ライブと抽出」の活用
  • ライブ接続(直接接続)
    • ユーザー操作による描画の際はSnowflakeにクエリを発行→クエリ処理はSnowflakeウェアハウス側で実行
    • 常に最新のデータがダッシュボードに反映=都度クエリ発行処理がSnowflake側に対して掛かる
  • 抽出接続
    • データをTableau Desktop/Serverの"ローカル"に抽出・保存
    • ユーザー操作による描画の際はその抽出データに対してクエリが発行される=Snowflake側に負荷は掛からない
    • ただし、最新データの反映には「抽出ファイルの更新」が必要
  • どちらを選択すべきか?
    • 一長一短ある
    • 二者択一では無く、データ更新の頻度や規模に応じて使い分ける
  • 併用案

ダッシュボードのパフォーマンス問題

  • 症状例
    • 開くのに時間が掛かる
    • フィルタ切替時の結果表示に時間が掛かる
  • ボトルネック
    • 同時実行性能、または単体クエリの処理性能に帰結
    • ピークタイム(始業時等)に多数のユーザーが実行する場合にのみ発生(同時実行性能の問題)
    • ピークタイムやユーザー数の大小に関わらず常に問題が発生(クエリ処理や描画性能の問題)

パフォーマンスのボトルネック

  • そもそもBI(Tableau)とSnowflakeでどういった処理の流れがあるのか?を図示したのがこちら。(Tableau ServerからSnowflakeにリクエストがあった場合の例)
    • ボトルネックになる場所は2箇所。1つはSnowflake側、もう1つはTableau側。
    • Snowflakeではこれらのボトルネックに対する対応方法、ソリューションを説明していく

ウェアハウスの最適化

  • 複数クエリの同時実行性能:マルチクラスターウェアハウスが有効。ユーザー数(実行クエリ)の増減に伴い、最大10クラスターまで自動的にスケールアウト(またはダウン)を行ってくれる
  • 単体クエリの処理性能
    • 単体クエリや描画処理がボトルネックになる場合は「ダッシュボードデザインの変更」を検討。
      • ダッシュボードデザインが悪いとパフォーマンスは出ない
      • デザインを変える=Snowflakeへ発行するクエリを変える
      • これは結果的にTableauの描画性能にも効いてくる
      • BI製品の特性に応じた効率的なダッシュボードデザインを目指そう
  • Tableauの描画性能

    まとめ

    • ライブと抽出を併用することでウェアハウスコストを抑制
    • 同時実行性能を向上するマルチクラスターウェアハウス
    • ダッシュボードデザインのベストプラクティスの重要性

まとめ

という訳で、SNOWDAY JAPANブレークアウトセッション「ビジネスの意思決定を加速する BI on Snowflake 設計の勘所」のレポートでした。こちらの内容を見ててふと「この課題とソリューション、RedshiftとTableauの組み合わせでも同じ問題に直面してたなぁ...」と昔を思い出しました。RedshiftがSnowflakeに変わっただけで、詰まるところ「ボトルネックになっているところ、解決方法は変わらない」のですね。「このノウハウはどのデータベース/データウェアハウスでも有効である」と言い換えることも出来るのだと思います。必要な情報を確認し、取りうる良策を積極的に取り入れて改善していきたいですね。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.